[HIP] [FlyDSL] Refactor gfx950 A16W16 GEMM with centralized policy selection and tuning - #5145

Conflict was kimik3_bf16_tuned_gemm.csv only, and it was textual rather than
semantic. ROCm#5145 retuned 184 rows of that file in place while this branch adds
7; the edits interleave in the same region, so git could not align the hunks.

The two sets do not overlap. Every row ROCm#5145 retuned is outdtype=bfloat16 and
every row this branch adds is outdtype=float32, and outdtype is part of the
index get_GEMM_A16W16_config_ builds, so the two address disjoint keys. The
merged-front GEMM writes an FP32 accumulator it slices router logits out of,
which is why its rows are the fp32 ones.

Resolved by key instead of by hunk: upstream's value for every row upstream
has, this branch's 7 added rows kept, upstream's row order preserved. Verified
that upstream neither reordered nor added/removed rows, that this branch only
appends and never edits a pre-existing row, and that no added key collides with
an upstream key -- if any of those had failed the resolution would not be
mechanical. Result is 536 rows, 536 unique keys, no ragged rows.

ROCm#5145 also refactored tuned_gemm.py, but only along the flydsl branch
(get_flydsl_splitk_hgemm_kernel_params was renamed and the kernel parameter
schema changed). This branch's rows are all libtype=hipblaslt and its code
touches only hipb_create_extension, _hipb_mm and get_GEMM_A16W16_config, whose
signature is unchanged. get_padded_m and the [None, 0, 1] lookup loop are also
untouched, so the M=8 -> padded 16 assumption behind the M=16 row still holds.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>